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METHOD, SYSTEM, AND PROGPIAM FOR IMPLEMENTING 



SCROLLABLE CURSORS IN A DISTRIBUTED DATABASE SYSTEM 



BACKGROUND OF THE INVENTION 



Field of the Invention 



The present invention relates to a method, system, and program for implementing 
scrollable cursors in a distributed database system. 

2. Description of the Related Art 

Prior art database programs include a feature referred to as cursors. A cursor is a 
named control structure used by an application program to point to a row of interest within 
some set of rows and to retrieve rows from the set, possibly making updates and deletions. A 
cursor points to rows from a database table that satisfy a structured query language (SQL) 
query against the table. The rows in the table that satisfy the SQL query comprise a result 
table of data. The SQL query includes an SQL SELECT statement and a WHERE clause to 
qualify rows according to a predicate. An appUcation can then access data on a row-by-row 
basis from the result table. 

When a cursor is opened or initialized, die current row position (current cursor position) 
is before the first row in the result table. The application program may issue fetch commands 
to move the current row position (current cursor position) and retrieve row data. Cursors are 
described in SQL099 standard and also the Open Database Connectivity (ODBC) 
architecture. Cursors may be updateable or non-updateable (read-only). An updateable 
cursor allows the application program to update or delete the row at the current cursor position 
~ this is known as updating or delating through the cursor. A non-updateable (read-only) 
cursor does not allow the apphcation program to perform such operations. 
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Cursors may be serial (non-scrollable) or scrollable. A serial (or non-scrollable) cursor 
is one that only allows the application to move forward through the result table. A scrollable 
cursor is one that allows the application program to move both forward 
and backward through the result table. Fetching forward in the result table increases the current 
5 cursor position while fetching backward decreases the current cursor position. 

Cursors may be insensitive or sensitive to updates. An insensitive cursor is one that 
does not show updates made to the underlying data for the cursor, whether the update is made 
through the cursor or by other concurrent processes. Otherwise, the cursor is sensitive to 
updates. There may be degrees of sensitivity defined by the implementation, but this patent does 
, 3 10 not distinguish degrees of sensitivity. Fetches against the cursor may be single-row fetches or 

; ^ multi-row fetches. A single-row fetch returns only one row in response to the fetch request. A 

U multi-row fetch returns a specified number of rows in response to the fetch. It is possible for a 

^ J database system to support single-row fetching without supporting multi-row fetching. 

In a distributed relational database environment, an apphcation program at a cUent 
□ 15 computer may request a cursor firom a database at a server computer. In the current art, the 

I y Distributed Relational Database Architecture (DRDA) specifies a protocol for a client 

j;^ computer to open a cursor and request data firom a cursor result table fi'om a database at a 

f'^ server. Because the overhead of communicating across the network is high, DRDA cUents and 

servers attempt to minimize the number of messages they exchange. In the current art, when a 
20 DRDA server receives a single-row fetch request for a read-only non-scrollable cursor, it 
fetches ahead additional rows and returns all the fetched rows in a single buffer, known as a 
query block. The query block is of a size negotiated between the client and the server. 
Because the apphcation can only move forward sequentially through the cursor, when the chent 
receives the query block, it satisfies the apphcation requests for rows fi*om the cursor by 
25 reading the locally available query block, thus saving additional message flows across the 

network. The protocol is known in DRDA as Limited Block Query Protocol. For updateable 
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non-scrollable cursors, fetching ahead is not possible since a row may be updated after it has 
been prefetched by the server but before it has been fetched by the apphcation. In this case, the 
DRDA Fixed Row Query Protocol is used. If the cUent and/or the server support only single- 
row fetch, this typically means that each remote fetch request retrieves one row of data at a 
time. 

When an apphcation presents a window to a user displaying rows of data and allows 
the user to scroll forward and backwards, scrollable cursors are the most appropriate stmcture 
by which to impleirient the apphcation. Typically, these modem windowing apphcations are 
interactive, requiring quick responses to actions in the window. Techniques used in prior art 
database systems introduce performance or concurrency problems for such scrollable cursor 
applications. For instance, the chent apphcation may frequently change the cursor position 
within the window. In such case, the chent cannot practically communicate with the server each 
time the cUent's window position is changed. Updateable cursors often employ techniques Uke 
DRDA Fbced Row Protocol to send only one row per network transmission. This guarantees 
the server data is unchanged between the fetch operation and any subsequent update. 
However, the network transmission overhead for this approach is prohibitive for query answer 
sets of any reasonable size. 'Wide" cursors that fetch multiple rows on a single operation 
alleviate the network performance problems, but introduce concurrency problems because all 
of the rows within the cursor are locked for updateable queries. 

Thus, there is a need in the art to provide an improved method for fetching 
cursor data in a chent/server environment. 

SUMMARY OF THE PREFERRED EMBODIMENTS 
Provided is a method, system, and program for accessing data in a distributed database 
environment. A client program receives multiple requests for data from a database object 
satisfying specified search predicates from an apphcation program. Each request includes a 



'is 
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request for at least one row from the table. The client program transfers a database command 
and a rowset parameter indicating a maximum number of rows to retum to a server program 
over a network if the requested row is not maintained by the client program. A data block is 
generated with the server program including rows from the database object satisfying the search 
5 predicates in response to the database command. The rows included in the data block do not 
exceed the rowset parameter. The server program transfers the data block to the client 
program. In turn, the cUent program returns at least one requested row from the received data 
block in response to one request for the at least one row of data from the application program. 
In fiirther embodiments, the server program maintains a maximum block size parameter, 

1 0 and wherein the data block is fiirther generated to not exceed the block size parameter. 

In still fiarther embodiments, the multiple requests received by the cUent program from 
the application program comprise single-row fetch requests. 

Still fiirther, the client program and server program may communicate using the 
Distributed Relational Database Architecture (DRDA). In such case, the database command 

1 5 transferred by the client program could comprises an open query command or a continue query 
command for rows from an open cursor. 

Preferred embodiments provide a technique for scrollable cursors to allow fetching 
ahead rows to retum to an application program that the appUcation program wiU request in 
subsequent data requests. A cUent program local to the application implementing the scrollable 

20 cursor would request a remote server program over a network to fetch multiple rows from a 
database object, such as a table or index. The client program could then service requests from 
the application program for data locally from the multiple fetched rows. Preferred 
embodiments are particularly usefiil for situations where the application program issues single- 
row fetch requests, such as the case with scrollable cursors. With the preferred embodiments, 

25 the cUent program does not have to issue requests to the remote server program over the 



-5- Express Mail No. EL821 158363US 

Docket No. STL920000078US 1 
Firm No. 0055.0028 

network in response to each single-row fetch request, but can instead service scrollable cursor 
single row fetch requests from multiple rows the client program fetched in advance. 

The described implementations provide an improved method for fetching cursor data in 
a cUent/server environment when the cursor presented to the appUcation is capable of only 
5 single-row fetch operations, but the underlying cUent and database system implementation is 
capable of exploiting multiple-row network transmissions and perform scrolling operations 
without frequent network interactions with the server. The improved method for fetching 
cursor data is capable of supporting scrollable cursors that are either updateable or read-only. 
Further, the described implementations optimize performance of scrollable cursor 

10 applications that use a single-row cursor interface (both read-only cursors and 

updateable cursors) by implementing cUent/server network protocols that allow the server to 
send a block of rows on each network transmission (rather than one row at a time for 
updateable cursors) in order to minimize network traffic by reducing the number of requests. 
The described implementations also allow the cUent to scroll back and forth within the block of 

1 5 rows without interacting with the server. In fact, network communication between the client 
and server is not necessary as long as the scroll 

operation at the client is contained within the block of rows currently resident at the client. This 
aspect provides optimal client scrolling performance by allowing the chent to operate on the 
rows "cached" at the chent without notifying the server. 
20 Still fiirther, the described implementations allow the client to resynchronize the cursor 

position at the server when the client needs a new block of rows. This allows the client to 
reposition the server's current position . This addresses the situation when the client may have 
changed cursor position without previously informing the server about the cursor position 
change. 
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BRffiF DESCRIPTION OF THE DRAWINGS 
Referring now to the drawings in which Uke reference numbers represents 
corresponding parts throughout: 

FIG. 1 illustrates a computing environment in which preferred embodiments are 
5 implemented; 

FIG. 2 illustrates data structures used by the components in the computing environment 
in accordance with preferred embodiments of the present invention; 

FIGs. 3-5 illustrate logic implemented by the components in the computing environment 
to return requested data to an application program in accordance with preferred embodiments 
10 of the present invention; 

FIG. 6 illustrates a distributed computing environment in which preferred embodiments 
are implemented; 

FIGs. 7-8 illustrate logic implemented by the components in the distributed computing 
environment to retum requested data to an application program in accordance with preferred 
1 5 embodiments of the present invention; 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
In the following description, reference is made to the accompanying drawings which 
form a part hereof, and which illustrate several embodiments of the present invention. It is 
20 understood that other embodiments may be utilized and structural and operational changes may 
be made without departing from the scope of the present invention. 

FIG. 1 illustrates a distributed computing environment in which preferred embodiments 
are implemented. A cUent computer 2 includes an appUcation program 4 and a DRDA client 6. 
A server computer 10 includes a DRDA server 12 and a database management system 
25 (DBMS) 14 known in the art, such as the International Business Machines Corporation DB2 
database program.** The client computer 2 and server computer 10 may comprise any 
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computer system known in the art, such as a server, workstation, personal computer, 
mainframe, etc. The application program 4 may comprise any application program that is 
capable of issuing scrollable cursor commands. The DRDA cUent 6 and DRDA server 12 
comprise DRDA client/server software known in the art for handling distributed database 
5 commands across clients and servers. Details of the DRDA client/server protocol for allowing 
data on one system to be shared and accessed by another system is described m the IBM 
publication "Distributed Data Management Architecture: General hiformation Level 4," having 
IBM document no. GC2 1-9527-03 (Copyright IBM, 1993) ^d the Open Group Technical 
Standards entitled "DRDA, Version 2, Volume 3: Distributed Data Management (DDM) 

10 Architecture", document no. C913 (Copyright The Open Group, 1993) and "Distributed 

Relational Database Architecture (DRDA), Version 2, Volume 1 (Copyright The Open Group, 
1999), which pubHcations are incorporated herein by reference in their entirety. 

The DBMS program 14 in the server 10 is capable of accessing a database 16 
including a database object 18, such as a database table or index. In the preferred 

1 5 embodiments, some component in the system, such as the database engine used by the 

application 4 in the client 2 or the DBMS 14 in the server 10 only provide for single-row fetch 
support, such that the appUcation 4 wiU only fetch one row at a time in order to scroll forward 
or backward through a result table. The application program 4 would defme a scrollable cursor 
using a database and WHERE predicate clause indicating predicates that rows in the scrollable 

20 cursor result table must satisfy to qualify as a result table row. 

Preferred embodiments provide additional parameters and algorithms implemented in 
the DRDA cUent 6 to optimize requests for data from the DRDA server 12 when the 
application program 4 is fetching multiple rows using single-fetch commands. In prefenred 
embodiments, the appHcation 4 requests to fetch one or more rows from a result table. The 

25 application 4 may specify one of the following types of FETCH request to fetch rows from a 
result table that satisfy predicates provided when defining a cursor or scrollable cursor. 
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NEXT : positions the cursor on the next row of the result table 34 relative to the current 
cursor position and fetches the row. NEXT is the default. 

PRIOR : positions the cursor on the previous row of the result table 34 relative to the 
current cursor position and fetches the row. 
5 FIRST : positions the cursor on the first row of the result table 34 and fetches the row. 

LAST : positions the cursor on the last row of the result table 34 and fetches the row. 
CURRENT : fetches the current row. 

BEFORE : positions the cursor before the first row of the result table 34. 
AFTER: positions the cursor after the last row of the result table 34. 
1 0 ABSOLUTE : Evaluates the host variable or integer constant to an integral value k, and 

then moves the cursor position to the A:th row in the result table 34 if /:> 0 or to A: rows 
from the bottom of the table if A: < 0 and fetches the row. 

RELATIVE : Evaluates the host variable or integer constant to an integral value k, and 
then moves the cursor position to row in the result table 34 k rows after the current row 
15 ]Sk>Qox\ok rows before the current row if A: < 0 and fetches the row. 

FIG. 2 illustrates fiirther data stmctures maintained by the DRDA client 6 to implement 
the preferred embodiments. The DRDA client 6 maintains the query block 30 that include the 
rows in the rowset that the DRDA server 12 fetched via the DBMS 14 from the database 
object 18 and returned to the DRDA client 6. The DRDA client 6 fiirther maintains a chent 
20 cursor position value 3 1 indicating the cursor position the appUcation 4 last accessed and a 
block position 32 that indicates the next row to parse when searching for the next row the 
apphcation 4 fetches from the client query blocks 30. In this way, the client query blocks 30 
buffer the rows fetched from the actual database object 18 that were retumed in query blocks 
from the DRDA server 12. 
25 The DBMS 14 maintains a DBMS result table 34, which is the result table maintained 

by the DBMS 14 that includes those rows in the database object that satisfy the cursor search 
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predicates. The DBMS cxirsor 36 points to the last row in the DBMS result table 36 returned 
to the DRDA server 12. Thus, both the DRDA client 6 and the DBMS 14 in the server 10 
maintain knowledge about the current cursor position, where the cUent cursor position 31 is the 
last row fetched by the application 4 and the DBMS cursor 36 is the last row fetched by the 
5 DRDA server 12. Since the DRDA server 12 fetches ahead of the application 4, these two 
values may be different at any given time. FIGs. 3, 4, and 5 illustrate logic implemented in the 
DRDA client 6 and DRDA server 12 to provide an improved technique for fetching across a 
network using the DRDA protocol when the application 4 or DBMS 14 is only capable of 
single-row fetch operations and not multi-row fetch operations. 

1 0 Upon receiving an SQL OPEN CURSOR request to initialize a scrollable cursor in the 

database object 18 for application 4, the DRDA chent 6 would then generate an OPNQRY 
message to send to the DRDA server 12. Upon receiving an SQL FETCH request to fetch 
rows from the result table for the scrollable cursor, the DRDA cUent 6 would generate a 
(continue query) CNTQRY message to send to the DRDA server 12. In the preferred 

1 5 embodiments, the DRDA chent 6 would specify a rowset parameter (QRYROWSET) 

indicating a number of rows to retrieve from the database 16 via DRDA server 12, allowing 
each message to request that multiple rows be sent by the DRDA server 12 to the DRDA cUent 
6 even though only single-row fetches are supported for the cursor. The rowset parameter 
(QRYROWSET) is used by the DRDA client 6 to indicate on the OPNQRY or CNTQRY 

20 message the maximum number of rows satisfying the query predicates of the cursor to be 
returned by the DRDA server 12 in response to the message. The rows requested by the 
DRDA client 6 constitute a rowset, comprising one or more query blocks. A query block, 
containing cursor data for at least one row, is the basic unit of transmission for cursor data in the 
DRDA protocol, where the size of each query block (QRYBLKSZ) and the number of 

25 additional query blocks (MAXBLKEXT) beyond those needed to transmit at least one row is 
negotiated between the DRDA client 6 and the DRDA server 12. 



• 4 
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A large row may span multiple query blocks, if the query block size is small relative to 
the row size. If extra query blocks are supported (MAXBLKEXT greater than zero), tiien 
more than one query block may be retumed. In this discussion, it is assumed that multiple rows 
can fit into a query block and only one query block is retumed for each message as other 
5 variations are easily understood from this case. The rows retumed by the DRDA server 12 may 
be a complete rowset or a partial rowset. A complete rowset is one that contains all the rows 
requested by tiie QRYROWSET parameter, until the end of the result table is encountered. A 
partial rowset is retumed if negotiated limits for query block size and the number of additional 
query blocks prevent the retum of all tiie rows requested. Because the DRDA server 12 

1 0 fetches ahead of the appUcation 4, the client cursor position 3 1 known to the application 4 may 
be different from tiie cursor position 36 maintained by the DBMS 14 at any given time. 

Further, since the number of rows retumed in response to an OPNQRY or CNTQRY 
message is dependent on die size of each row retrieved, tiie query block size, and the particular 
extra query block implementation of tiie DRDA server 12, tiie DRDA client 6 does not know 

1 5 which rows are contained in flie query block(s) nor does it know tiie cursor position 36 
maintained by tiie DBMS 14 without parsing flie entire retumed query block(s). Finally, the 
FETCH requests generated by tiie application 4, along witii any orientation specifications, are 
relative to the cUent cursor position 3 1 of tiie appUcation, and not the value of tiie cursor 
position 36 maintained by the DBMS 14. In such implementations, the DRDA client 6 

20 manages the differences between the cUent cursor position 3 1 and tiie cursor position 36 at the 
DBMS 14. In certain implementations, tiie DRDA client 6 could enforce a requirement tiiat for 
every rowset retrieved from the DRDA server 12, tiie appUcation 4 must fetch every row in the 
rowset before another rowset is retrieved from the DRDA server 12. If this requirement is not 
enforced, flien otiier methods may be employed by flie DRDA cUent 6 to map between the 

25 fetch request generated by tiie application 4 and the correct behavior at the DBMS 14. In this 
description, for illustration purposes, tiie DRDA cUent 6 is assumed to maintain tiie absolute 
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row position fetched by the application and all CNTQRY request that are dependent on the 
current position 36 at the DBMS 14 are mapped to FETCH ABSOLUTE requests. 

In addition, it is assumed that all rowsets retrieved are complete in FIGs. 3, 4, and 5. 
Details concerning partial rowsets processing are provided in the discussion with respect to 
5 FIGs. 7, 8, and 9 below. In certain implementations, messages exchanged between the DRDA 
client 6 and the DRDA server 12 conform to the DRDA Umited block query protocol 
(LMTBLKPRC) or the fixed row query protocol (FIXROWPRC). However, altemative query 
protocols may be utihzed, such as the continuous block fetch protocol or any other block 
transfer protocol known in the art. 

1 0 The application 4 and DBMS 14 would perform fetch operations in a manner known to 

the art, which would trigger the logic described in FIGs. 3, 4, and 5 to access the rows fi"om the 
DRDA server 16. With respect to FIG. 3, control begins at block 100 with the appUcation 4 
generating an SQL open cursor request (OPEN CURSOR) to initiate a scrollable cursor. The 
DRDA client 6 receives (at block 1 10) the open cursor request and, in response, generates (at 

1 5 block 1 12) a DRDA open query message (OPNQRY) to initiate a scrollable cursor with a 
rowset size (QRYROWSET) of S. Providing a rowset may be optional. The DRDA cUent 6 
then sends (at block 1 14) the generated OPNQRY message with the QRYROWSET 
parameter to the DRDA server 12. At block 120, the DRDA server 12 receives and parses the 
message fi*om the DRDA client 6. In response, the DRDA server 12 generates (at block 122) 

20 an SQL open cursor request, which is passed to the DBMS 14 across a program interface in 
the server 10. At block 130, the DBMS 14 receives (at block 130) the SQL open cursor 
request firom the DRDA server 12 and executes (at block 132) the SQL open cursor request in 
a manner known in the art. In opening the cursor, the DBMS 14 creates (at block 134) the 
DBMS cursor 36 positioned before the first row that satisfies the cursor query predicates 

25 specified with the open cursor request. The DBMS 14 then returns (at block 136) to the 

DRDA server 12 the status of the open cursor operation. The DRDA server 12 receives (at 
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block 140) and processes the open cursor complete status. The DRDA server 12 generates (at 
block 142) an open query reply message and a descriptor message that will eventually be sent 
to the DRDA cUent 4. The DRDA server 12 begins the process of accessing rows in the 
DBMS result table 34 to include in a query block to send to the DRDA cUent 6. In this way, 
5 the DRDA client 6 can respond to single-row or muUt-row FETCH requests from the 

application 4 from the multiple rows from the result table 34 returned in the query block 30. 

The DRDA server 12 (at block 176) adheres to DRDA block rules in determining if 
there is sufficient room in the query block containing the open query reply message and 
descriptor message to contain none of, all of, or only a portion of the first row. In certain 
O 10 implementations, the first row is not appended to the query block if the query block cannot 

i' n 

contain the whole row. However, other variations are also possible. Assuming that there is 
room in the query for the first row, the DRDA server 12 generates (at block 150 in FIG. 4) an 
'^^J SQL FETCH request to fetch the next row in the result table and passes the request to the 

;i DBMS 14. In response to receiving the FETCH request from the DRDA server 12, the DBMS 

I J 15 14 executes (at block 160) the FETCH to move the cursor 36 to the next qualifying row in the 

[ y database object 1 8. If (at block 1 62) a row (or the SELECT columns) is returned, then the 

13 DBMS 14 returns (at block 4) the fetched row to the DRDA server 12. Otherwise, if the end 

of the database object 1 8 has been reached, then a status is retumed with an SQLSTATE (at 
block 166) indicating no further rows to fetch. When the end of the database object 18 is 
20 reached, the rows already fetched into the rowset by the DRDA server 12 constitute a 

complete rowset. Otherwise, the rowset is incomplete and the DRDA server 12 continues to 
fetch into the rowset until it is complete (eitiier the number of rows in the rowset is equal to the 
requested QRYROWSET or the end of the database object 1 8 is reached) or an error occurs 
when fetching yielding an error SQLSTATE for the FETCH request. 
25 In response to receiving the retumed qualifying row or selected columns in the row 

from the DBMS 14 at block 164, the DRDA server 12 appends (at block 170) the retumed 
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row or columns to the query block 30 being constructed to return to the DRDA client 6 and 
increments (at block 1 72) a row counter variable that is used to ensure that the number of rows 
appended to the query block do not exceed the specified rowset parameter (QRYROWSET). 
If (at block 174) the row counter is not equal to the rowset parameter (QRYROWSET), i.e., 
5 the rowset is incomplete and there are further rows to access to return the rowset parameter 
number of rows, then the DRDA server 12 determines (at block 176) whether another 
quaUfying row can be added to the query block 30 without exceeding the query block size 
(QRYBLKSZ) of the DRDA server 12 query block and without exceeding the negotiated extra 
query block limits (MAXBLKEXT). If these hmits are not exceeded, then control returns to 

1 0 block 1 50 to fetch the next quaUfying row from the result table 34 to include in the query block 
30. In preferred embodiments, the DRDA server 12 will only request a number of rows that is 
needed to complete the rowset size. Otherwise, if adding another row or the selected columns 
would exceed the hmits, then the DRDA server 12 would further transmit the generated query 
block. In the case of an OPNQRY message, the query block would contain the open query 

1 5 reply message, the descriptor message, and the rows fetched for the rowset. If (at block 174) 
the server query block 30 includes a number of rows equal to the rowset size (i.e., row counter 
variable equals QRYROWSET), then the server query block is returned at block 178 to the 
DRDA client 6. 



20 query reply and descriptor messages as described in the current art and sets (at block 192) the 
block position to the first row of data in the client query block. The client cursor position 3 1 is 
initialized to zero, indicating that no rows have been fetched by the appUcation 4. The DRDA 
client 6 (at block 194) returns the open cursor complete status to the application 4. Upon 
receiving (at block 200) the indication that the open cursor completed successfully, the 

25 application 4 generates (at block 202) a SQL FETCH request to fetch a row in the result table 
and passes the request to the DRDA cUent 6. The fetch request passed to the DRDA client 6 



Upon receiving the query block (at block 190), the DRDA client 6 parses the open 
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may include orientation parameters, such as fetch next, forward by a relative or absolute 
amount, or backward by an absolute amount. At block 210, the DRDA client 6 receives the 
fetch request from the application 4 and determines (at block 2 12) if the requested row is in the 
query block 30 by parsing the query block and looking for the desired row or by using some 
5 other method, such as interpreting the fetch orientation parameters, to determine if the row is in 
the query block. If (at block 212) the requested row is in the query block 30, then the DRDA 
chent 6 (at block 214) updates the client cursor position value and returns the row to the 
application 4. In this way, the DRDA client 6 services fetch requests from data prefetched by 
the DRDA server 12 from the database object 18. Thus, with preferred embodiments, when 

10 the DRDA cUent 6 only supports single-row fetching for scrollable cursors, the DRDA client 6 
nevertheless can efficiently retrieve multiple rows and save on network transmission costs. 

If the requested row is not in the received query block 30, then the DRDA cUent 6 
proceeds (at block 216) to block 230 in FIG. 5 to generate a CNTQRY message with rowset 
size and positioning specification to indicate the desired row, taking into account any differences 

1 5 between the current client cursor position and the current server cursor position. Because this 
discussion assumes that the previous rowset was complete, the DRDA cHent 6 merely specifies 
a new rowset value to start a new rowset. At block 232, the DRDA client 6 sends the 
CNTQRY message to the DRDA server 12 to request the desired row. The DRDA server 12 
(at block 240) generates the FETCH request for the desired row. At block 242, the DRDA 

20 server 12, builds the query block by performing blocks 170-178 in FIG. 4 to add the rows to 
the query block, and then repeats blocks 150 and 170-178 to generate the remainder of the 
query blocking containing the rows in the rowset to return. At block 250, the DBMS 14 would 
performs steps 160-166 to fetch the rows from the result table 34 in the database object 18 
and retum to the database server either the fetched row or a SQLSTATE indicate that the end 

25 of the database object is reached. 



i 
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After filling the query block 30 in response to the CNTQRY command with the rowset 
parameter specified, the DRDA server 12 returns (at block 242) the query block 30 to the 
DRDA cUent 6. In response, at block 260, the DRDA cUent 6 receives the query block and, at 
block 262, goes to block 214 to look for the desired row response in the query block, which 
5 should be there because the row was just fetched. The application 4 would perform steps 220 
to 224 to fetch further data or to close the cursor. With preferred embodiments, performance is 
improved with database engines that only support single-row fetches because the DRDA cUent 
6 can return requested data fi*om a local query block 30 without having to fetch across the 
network for each application FETCH operation. Instead, the described implementations 
1 0 provide data structures and a methodology for maximizing the number of records transferred 
across the network in a query block, yet taking into account the possibihty that an apphcation 
may scroll randomly forward and backward within the cursor, thus potentially causing skipping 
of retrieved rows in the query block. 



1 5 complete - that is, it contained all rows requested by the QRYROWSET parameter, but 
rowsets may be either complete or partial. In the following discussion, processing of partial 
rowsets is considered in the context of an intermediate server. FIG. 6 illustrates a computing 
environment in which a DRDA cUent 6 sends DRDA messages to DRDA server 12 by way of 
an intermediate server 50 and an intermediate DRDA server 52. The intermediate DRDA 

20 server 52 and the DRDA server 12 transmit query blocks 56 and 58 respectively, where the 
number of rows in the query blocks may be different because the blocking limits between the 
DRDA client 6 and the intermediate DRDA server 52 may be different from the blocking limits 
between the intermediate DRDA server 52 and the DRDA server 12. In the example described 
herein, the DRDA client 6 sends a CNTQRY with a QRYROWSET value of S, while the 

25 blocking limits allow the DRDA server 12 and the intemiediate DRDA server 52 to return 
partial rowsets of size SI and S2 respectively (SI < S and S2 < SI). 



In the above discussion, each rowset returned by the DRDA server was assumed to be 
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FIGs. 7-8 illustrate the logic implemented by the DRDA cUent 6, the intemaediate 
DPUDA server 52, and the DPIDA server 12 when a CNTQRY request with a QRYROWSET 
value of S results in partial rowsets being returned by the intermediate DRDA server 52 and the 
DRDA server 12. In FIG. 7 at block 300, the DRDA cUent 6 generates and sends a 
5 CNTQRY message to the intermediate DRDA server 52, specifying a QRYROWSET value of 
S. In this implementation, the DRDA cUent 6 wants to retrieve all the S rows in the rowset to 
retum to the application 4, and will fetch all rows from the query blocks received in response to 
the CNTQRY message. At block 3 10, the intermediate DRDA server 52 receives the 
CNTQRY message and the QRYROWSET value of S. At block 312, the intermediate 

10 DRDA server 52 determines that the target database object 18 is on another server, and, at 
block 3 14, generates a different CNTQRY message with a QRYROWSET value of S to send 
to the DRDA server 12. The DRDA cHent 6 does not know that another server will process the 
CNTQRY message, nor does the intermediate DRDA server 52 know if the DRDA server 12 
actually contains the target database object. In this example, it is assumed that the server 10 

1 5 contains the target database object 1 8, At block 320, the DRDA server 1 2 performs blocks 
240 and 242 as in FIG. 5, receiving the CNTQRY message from the intermediate DRDA 
server 52, building the FETCH requests to the target database 16, and generating the query 
blocks. As in our assumptions, the DRDA server 12 can only retum SI < S rows to the 
intermediate DRDA server 52. At block 330, the intermediate DRDA server 52 receives the 

20 query blocks containing the partial rowset from the DRDA server 12 and, for purposes of 
illustration, stores them in a query block buffer 60. At block 332, the intermediate DRDA 
server 52 generates query blocks to retum to the DRDA client 6. As in our assumptions, the 
intermediate DRDA sever can only retum S2 < SI rows to the DRDA client. 



25 leaving S 1 - S2 rows in the query block buffer 60. At block 340, the DRDA client 6 receives 
the query blocks from the intermediate DRDA server 52 using the logic as in block 260 and 



The S2 rows are taken from the query blocks received from the DRDA server 12, 
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262 in FIG. 5. Upon fetching all S2 rows in the query blocks received from the intermediate 
DRDA server 52, the DRDA client 6 will generate (at block 344) another CNTQRY message 
with QRYROWSET value of S - S2 to retrieve the remaining rows in the pending rowset. At 
block 350, the intermediate DRDA server 52, receives and vaUdates the aSTTQRY message 
5 with the QRYROWSET value of S - S2. Since SI - S2 rows were previously received from 
the DRDA server 12, the intermediate DRDA server 52 adds those rows the query blocks to 
retum to the DRDA client 6 (block 352), then generates a different CNTQRY with a 
QRYROWSET value of S - SI to send to the DRDA server 12. At block 362, the DRDA 
server 12 receives the CNTQRY message and builds the query blocks for the remaining S - SI 

10 rows in the rowset as in block 320 and 322. If all S - SI rows can be returned, then the rowset 
is complete, otherwise, the DRDA server 12 just sends the rows up to the block size limit and 
once again retums a partial rowset. 

At block 370, the intermediate DRDA server 52 performs blocks 330 and 334 to 
receive the query blocks into the query block buffer 60. If all S - S2 rows can be returned, 

1 5 then the rowset is complete, otherwise the intermediate DRDA server 52 just sends the rows it 
can and once again retums a partial rowset. At block 380, the DRDA cUent 6 receives the 
query blocks containing the rows returned in response to its CNTQRY command, performing 
the logic as in blocks 340 and 344. If all S - S2 rows were not received, then repeat blocks 
340 to 380 until this is true. When a DRDA cUent 6 receives a partial rowset, it either must 

20 complete the rowset as described above in FIG. 7-8 or it must reset it by means of a 
CNTQRY parameter QRYBLKRST. 

In the described implementation of FIGs. 7 and 8, SI is greater than S2. 
If S2 is greater than SI, then the intermediate site will receive fewer rows from the 
downstream serving site than it can send to its upstream requesting site. In such case, the 

25 intermediate site requests the remainder of the rowset from the downstream serving site. The 
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intermediate site would send a CNTQRY to get more rows from the downstream serving site 
until it gets the maximum number of S2 rows that it can send. 

The described implementations provide an improved method for fetching 
cursor data in a chent/server environment when the cursor presented to the appUcation is 
5 capable of only single-row fetch operations, but the underlying client and database system 
implementation is able to exploit multiple-row network transmissions and perform scrolling 
operations without frequent network interactions with the server. The described 
implementations optimize performance of scrollable cursor appUcations that use a single-row 
cursor interface (both read-only cursors and updateable cursors) by implementing cUent/server 

10 network protocols that allow the server to send a block of rows on each network transmission 
(rather than one row at a time for updateable cursors) in order to minimize network traffic by 
reducing the number of requests. Still further, the described implementations allow the cUent to 
resynchronize the cursor position at the server when the cUent needs a new block of rows in 
order to reposition the server's current position The addresses the situation where the cUent 

1 5 may have changed cursor position v^thout previously informing the server about the cursor 
position change. 

Alternative Embodiments and Conclusions 
This concludes the description of the preferred embodiments of the invention. The 
20 following describes some alternative embodiments for accomphshing the present invention. 

The preferred embodiments may be implemented as a method, program using standard 
programming and/or engineering techniques to produce software, fmnware, hardware, or any 
combination thereof The programs and code defining the fimctions of the preferred 
embodiments can be dehvered to a computer via a variety of information bearing media, which 
25 include, but are not Umited to, computer-readable devices, firmware, programmable logic, 

memory devices (e.g., EEPROMs, ROMs, PROMs, RAMs, SRAMs, etc.)"floppy disk," CD- 
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ROM, a file server providing access to the programs via a network transmission line, wireless 
transmission media, signals propagating through space, radio waves, infiared signals, etc. Still 
further the code in which the preferred embodiments are implemented may comprise hardware 
or electronic devices including logic to process data. Of course, those skilled in the art will 
5 recognize that many modifications may be made to this configuration v^thout departing from the 
scope of the present invention. 

The preferred logic of FIGs. 3-5 and 7-9 describe specific operations occurring in a 
particular order. In alternative embodiments, certain of the logic operations may be performed 
in a different order, modified or removed and still implement preferred embodiments of the 

1 0 present invention. Morever, steps may be added to the above described logic and still conform 
to the preferred embodiments. Further, operations described herein may occur sequentially or 
certain operations may be processed in parallel. 

Preferred embodiments were described with respect to a situation where the 
application issues single row FETCH requests to fetch multiple rows firom a cursor table in a 

1 5 DRDA environment. The preferred embodiments may also apply to requests from the 
application for multiple rows, i.e., when the application supports multiple-row fetching. 

Preferred embodiments were described with respect to a computing network 
environment that utilized the DRDA protocol for SQL requests across a network. However, 
those skilled in the art wWi recognize that the preferred embodiments may be implemented in 

20 database network protocols other than DRDA. 

In summary, the present invention provides a system, method, and program 
for accessing data in a distributed database environment. A cUent program receives multiple 
requests for at least one row of data from a database object satisfying specified search 
predicates from an appUcation program. Each request includes a request for at least one row 

25 from the table satisfying the specified search predicates. The client program transfers a 

database command and a rowset parameter indicating a maximum number of rows to retum to 
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a server program over a netwode if the requested row is not maintained by Ae client program. 
A data block is generated with the server program including rows iiom the database object 
satisQ^ the ^arch predicates in response to the database comtnand The rows included in 
die data block do not exceed die xowset parameter. The serverprogram transfers the data 
block to die client program. In tuni, die cUent program r^urns at least oxie requested row fiom 
the received data block in response to one request for the at least one row of data fiom the 
applicadon program. 

Hie foregoing description of the preferred embodim^ts of the invention has been 
presented for die purposes of illustration and description. It is not intended to be exhaustive or 
to limit the invention to die precise form disclosed Many modifications and variations are 
possible in light ofthe above teaching. It is intended diat die scope ofdie invention be limited 
not by diis detailed description, but radier by die claims upended hereto. The above 
specification, examples and data provide a complete description of the manufacture and use of 
die composition of the invention. Since many embodiments ofthe invention can be made 
widiout departing fiom die ^irit and scope of the invention, die invention resides in the claims 
hereinafter appended 



*♦ DB2 is a registered trademark of International Business Machines Corp. 



